Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler warning with fileno when building with non-gnu C extensions #926

Closed
wants to merge 1 commit into from

Conversation

pmqs
Copy link
Contributor

@pmqs pmqs commented Feb 5, 2024

Building zlib throws up this compiler warning when the non-gnu extensions are enabled - so that is with gcc & clang using the -std option with any of the values c99, c11, c17, and c2x. This issue was found using the workflow file contained in #925

gcc -std=c2x -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -I. -c -o minigzip.o test/minigzip.c
test/minigzip.c: In function ‘main’:
test/minigzip.c:538:28: warning: implicit declaration of function ‘fileno’ [-Wimplicit-function-declaration]
  538 |             file = gzdopen(fileno(stdin), "rb");
      |                            ^~~~~~
gcc -std=c2x -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN  -o minigzip minigzip.o -L. libz.a
gcc -std=c2x -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzipsh minigzip.o  -L. libz.so.1.3.1.1-motley
gcc -std=c2x -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -I. -D_FILE_OFFSET_BITS=64 -c -o minigzip64.o test/minigzip.c
test/minigzip.c: In function ‘main’:
test/minigzip.c:538:28: warning: implicit declaration of function ‘fileno’ [-Wimplicit-function-declaration]
  538 |             file = gzdopen(fileno(stdin), "rb");
      |                            ^~~~~~
gcc -std=c2x -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN  -o minigzip64 minigzip64.o -L. libz.a

Looking at fileno in stdio.h on my Ubuntu setup I see it is guarded by __USE_POSIX

#ifdef	__USE_POSIX
/* Return the system file descriptor for STREAM.  */
extern int fileno (FILE *__stream) __THROW __wur;
#endif /* Use POSIX.  */

This change mirrors what is done in gzguts.h to define _POSIX_SOURCE if it isn't already defined.

@madler
Copy link
Owner

madler commented Feb 5, 2024

Applied.

@madler madler closed this Feb 5, 2024
@pmqs
Copy link
Contributor Author

pmqs commented Feb 5, 2024

Applied.

@madler, just spotted a failure in the MacOS clang build with this change (see https://github.com/madler/zlib/actions/runs/7789724438/job/21241964719 and https://github.com/madler/zlib/actions/runs/7789724436/job/21241964381)

clang -fPIC -DHAVE_HIDDEN  -DPIC -c -o objs/adler32.o adler32.c
test/minigzip.c:410:5: error: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Werror,-Wimplicit-function-declaration]
    snprintf(outfile, sizeof(outfile), "%s%s", file, GZ_SUFFIX);
    ^
test/minigzip.c:410:5: note: include the header <stdio.h> or explicitly provide a declaration for 'snprintf'
1 error generated.

Backing out this change makes the issue go away.

Interestingly the Mac builds using gcc work fine with this change (see https://github.com/madler/zlib/actions/runs/7789724436/job/21241964567).

Does clang on a Mac differ from the Linux version enough to mean that this isn't an issue on Linux, but is on Mac?

@madler
Copy link
Owner

madler commented Feb 6, 2024

Yes, I develop on a Mac. I changed it to # define _POSIX_C_SOURCE 200809L.

@madler
Copy link
Owner

madler commented Feb 6, 2024

After some testing, I changed that to 200112L so it would work on Solaris.

@pmqs
Copy link
Contributor Author

pmqs commented Feb 6, 2024

@madler I merged the 200112L into my fork & ran the workflow in #925 with this change included

All is fine apart from the combination of Ubuntu + clang + cmake with c89 or iso9899:199409

Error in both cases is

 [ 18%] Building C object CMakeFiles/zlib.dir/gzlib.c.o
/home/runner/work/zlib/zlib/gzlib.c:204:15: error: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Werror,-Wimplicit-function-declaration]
        (void)snprintf(state->path, len + 1, "%s", (const char *)path);
              ^
/home/runner/work/zlib/zlib/gzlib.c:204:15: note: include the header <stdio.h> or explicitly provide a declaration for 'snprintf'
1 error generated.

It does work with the configure build, so the issue must to be something in the generation of zconf.h and/or the command-line options passed to the C compiler.

Right - I see the issue. The configure build adds -DNO_vsnprintf but the cmake build does not. Adding that by hand makes the issue go away.

Don't see any code in CMakeLists.txt that runs test compilations that I can use as inspiration. I'll add an issue for this edge case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants